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PROPRIETARY NOTICE 

The technical content set forth in this document is the 
property o£ Control Data and is not to be disseminated, 
distributed or otherwise conveyed to third parties without the 
express written permission o£ Control Data. 

This document is to be used for planning purposes only. It 
does not include any explicit or implied commitments for any 
specific release dates or feature content. These matters are 
currently under active development, and as such are subject to 
revision and replanning as circumstances warrant. 
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1.0 INTRODUCTION 






1.0 INTRODUCTION 



This docuaent doscribea the internal design of the Internet 
Protocol (IP) aodule. The IP aodule implenent* the full DoD 
IP protocol, and adds soae ainor features not in the DoD 
specification. The IP aodule includes both the IP and the 
ICMP protocols. Due to the fact that the DI hardware is 
capable of connecting to aany networks at the saae tiae, the 
IP aodule extends the DoD specification by providing a 
datagraa forwarding service between any nuaber of connected IP 
networks. Routing decisions are not aade by the IP aodule, 
instead the IP static routing aodule aakes all necessary 
routing decisions. 

In the CDCNET environaent the IP aodule will use the 3A 
intranet aodule. This allows the IP protocol to be active on 
any of the network solutions that the DI software and hardware 
provide. 
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2.0 REFERENCES 



The following manuals contain naterial that either defines 
the operations of the IF nodule and the aodules it interfaces 
to, or provides additional insight into the use of the IP 
module. 

[1] RFC-791 SRI Internet Protocol 

[2] RFC-792 SRI Internet Control Message Protocol 

[3] MIL-STD-1777 DoD Internet Protocol Standard 

[4] ARH6265 CDC DoD Internet Protocol ERS 

[5] ARH6879 CDC 3A Intranet ERS 

[6] JRL3... CDC DoD IP Static Routing ERS 
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o 



3.0 ENVIRONMENT 

3.1 HARDWARE 



The IP nodule hai no special hardware requirement* . The IP 
module if part of the CDCNET aoftware and will run on a 68000 
based Device Interface (DI) . The module will be written in 
the CYBIL language, and will be compiled and bound using SES 
tools on a CYBER mainframe. 

3.2 SOFTWARE 



The IP module depends on a number of other software 
components in order to function in the DI. The following 
sections list these components and itemize the services of 
each component that the IP module uses. 

3.2.1 3A INTRANET MODULE 



The 3A Internet module provides a basic point-to-point data 
transfer service between two systems connected to a common 
network solution. The interface between the IP module and the 
3A module will require that the following services be provided 
by the two modules. 

1. The 3A module will provide an open SAP service such that 
the IP module is able to «pen a SAP through which it 
will receive datagrams from all IP type network 
solutions. 

2. The 3A module will provide a routine which the IP module 
will call to send datagrams to other connected systems. 

3. The IP module will provide a routine that the 3A module 
will call to present datagrams that are received on IP 
network solutions. 

4. The IP module will provide a routine that the 3A module 
will call to present status indications for all IP 
network solutions. This status will include the maximum 
datagram size for each network. 
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3.2.2 IP ROUTING MODULE 



3.2.2 IP ROUTING MODULE 



The IP module does not aake any routing decisions, for each 
datagram that it receives from an upper layer module or the 3A 
module, the IP routing module is called to determine the next 
destination of the datagram. The IP routing module provides a 
routine which uses the source addrisss, the destination 
address, and the IP options of the datagram to determine the 
next destination that the datagram should be sent to. This 
routine will then return the source address, destination 
address, the type of destination, and the maximum datagram 
size to the IP module The IP module can then route the 
datagram to the proper location. 

3.2.3 STATISTICS MANAGER 



The IP module will provide a report procedure that the 
statistics manager can call to display the statistics that the 
IP module has collected. A statistics SAP will be opened 
during initialization, and the required pointers will provided 
to the statistics manager. 

3.2.4 EXECUTIVE COMMON ROUTINES 



The IP module will use a number of the common subroutines 
that are provided as part of the executive. The following 
services will be expected from the executive. 

1. Timer interrupts. 

2. Buffer creation. 

3. Buffer destruction. 

4. Addition of data to buffers. 

5. Removal of data from buffers. 

6. Intertask messages. 
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4.0 DESIGN OVERVIEW 



The IP Bodule provides the ability fco tranimit datagrams 
throughout a packet-switched internetwork. This service is 
provided as a number of direct subroutine calls. The IP 
module will not run as a task in the DI due the simplicity of 
the processing that it does. Each task that uses a service of 
the IP module will provide the cpu time that the subroutines 
in the IP module need to provide that service. The following 
page contains a diagram of the flow of execution thru the IP 
module. The subroutine names listed below correspond to the 
numbers in the diagram. 

1. Receive_ULP_Data 

2. Receive_3A_Data 

3. Process_IP_Datagram 

4. Process_Fragment 

5. Process_ICMP_Datagram 

6. Generate_iaiP_Datagram 

7. Generate_Fragment 

8. Open_SAP_Processor 

9. Close_SAP_Processor 

10. Process_Timer_event 

11. Receive 3A Status 
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OVERVIEW 
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4.0 DESIGN OVERVIEW 

4.1 FUNCTIONAL STRUCTURE 



4.1 FUNCTIONAL STRUCTURE 



4.1.1 CLOSE SAP PROCESSOR 



The clo»e_SAP routine is called by the ULP to clo«e an open 
SAP. This "will clear the data structure and allow another 
■odule to use the released protocol nuober. This routine 
should be called by the ULP as soon as it is done transmitting 
datagrams with the particular protocol number. 

Call format 



PROCEDURE ip_close_sap ( 
protocol ~ : 0.7255; 
sapid : INTEGER; 
VAR status ; ip_status_type) ; 



protocol In This value specifies the user 

protocol to the IP module. 

tapid In This is the SAPid returned on the 

original open request. 

status Out This is the status of the 

request. The following values may 
be returned: 

ip__successful 

ip_s ap_no t_open 



Global data accessed 

1. The Protocol Status Table (PST) is updated and the PST 
record is deleted. 

2. Any Reassembly Buffers in use are released. 

3. The Statistics Data Structure (SDS) is updated. 
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4.0 DESIGN OVERVIEW 
4.1.1 CLOSE SAP PROCESSOR 



General Algorithm 



BEGIN 
IF 



the SAPID is in use THEN 
Clear the PST record pointer; 
Release any reassembly buffers; 
Release the PST record; 
IF (ten or nbre unused protocols) THEN 
Reduce the array size; 

ifend; 

Update the SDS counters; 

Force statistics for the protocol; 

Release the statistics record for the protocol; 

RETURN (ip_successful) 
ELSE 

RETURN (ip_sap_not_open) 
IFEND 



ENDl 
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4.1.2 GENERATE ICMP DATAGRAM 



4.1.2 GENERATE ICMP DATAGRAM 



This routine it called by the proceif_ip_datagram routine 
in order to generate a ICMP datagrun. The appropriate 
information will be paised in to describe the ts^e of error 
that has been detected. The datagram will be created and sent 
to the sender of the datagram in error. 

Call format 



o 



PROCEDURE generate_icmp_datagram ( 
ip_header; 
ip_option__rec; 
iemp status_type; 
INTEGER; 
INTEGER; 
ip_address; 
buf_ptr) ; 



header 

options 

•rror_type 

error_code 

error_ptr 

new_addres8 

data 



header 



options 



In 



In 



error_type In 



o 



error code In 



This is a record which contains 
all of the information that was 
contained in the IF header of the 
datagram that is in error. 

This is a byte array which 
contains the options that the IP 
header included. 

This is the type of ICMP datagram 
that should be sent. The following 
types of datagrams may be sent. 

icmp_echo_reply 

i emp_des t_unr eachab 1 e 

i cmp_s our ce_queneh 
. iemp^redirect 

i cmp_echo_r eques t 

i cmp__t ime_exceeded 

icmp__parameter__error 

i emp_t ime_r eques t 

i cmp_t ime__rep ly 

iemp_inf o_reque8 1 

icmp_info_reply 

This is the code that is passed 
in the datagram and determines the 



CONTROL DATA PRIVATE 



DOD Internet Protocol IDS 



A-6 
85/09/2A 



4.0 DESIGN OVERVIEW 

4.1.2 GENERATE ICMF DATAGRAM 






error_ptr In 



new address In 



data 



In 



Global data accessed 



1. None. 



General Algorithm 



specific error with the type. The 
value of this parameter is dependent 
on the type parameter. 

This is a pointer to the byte in 
error for the case of parameter 
errors. 



This is the new 
redirect datagram. 



address for a 



This is a pointer to the data to 
be sent with the ICMF datagram. For 
most error types the data buffer 
will contain the data portion of the 
datagram in error, only the internet 
header and the. first 64 data bytes 
will be used. In the case of Echo, 
Timestamp, and information 
datagrams, the data buffer will 
contain all data comprising the ICMF 
datagram except for the first word 
t^ich contains the type, code, and 
checksum. 



V / 



BEGIN 

Build the IP header. 

Compute the IP checksum. 

Build first word of datagram. 

Build remainder of datagram (depends on error_type) 

Compute the ICMF checksum. 

Send the datagram. 
END 
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4.0 DESIGN OVERVIEW 

4.1.3 GENERATE IP FRAGMENTS 



4.1.3 GENERATE IP FRAGMENTS 



Thi« routine is called by the proceii_ip_datagram routine 
in order to fragment a datagram that ii too large to be 
transmitted on the appropriate network. The datagram will be 
divided into a number of fragments and each fragment will be 
sent out through the 3A module. 

Call format 



PROCEDURE generate_ip_fragments ( 



header 
options 
data 
max__size 

network_id 
system_id 



header 



options 



data 



max size 



network id 



system_id 



In 



In 



In 



In 



In 



In 






ip_header; 

ip_option_ree; 

buf_ptr; 

INTEGER; 

net_id_type; 

sys_id__type) ; 



This is a record which contains 
the header of the datagram that 
needs to be fragmented. 

This is a byte array which 
contains the options that the IP 
header should include. 



This is a pointer to the data 
be sent with the IP datagram. 



to 



This is the maximum number of 
bytes that each datagram is allowed 
to contain. 

This is the 3A identifier for the 
network that the datagram is being 
sent to. 

This is the 3A identifier for the 
the specific host that the datagram 
is intended for. 
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Global data accessed 



1. None. 



General Algorithm 



BEGIN 

IF NOT header. dont_f rag THEN 

daax :- ■ax_size - options_size - 20; 
dmax :- dmax - (dmax MOD 8); 
fcotint :- 0; 
VffllLE dataoNIL DO 

Remove dmax byte* from the data buffer. 

header. offset :- f count; 

header. more frags :- (data<>NIL) ; 

IF fcount-0~THEN 

Build the fragment with all options. 
ELSE 

Build the fragment with repeat options only. 
ifend; 

Send the fragment through 3A. 
f count :- f count + dmax; 

hhilend; 

ELSE 

ReturnCip fragmentation_needed) ; 

ifend; 

END 



v J 
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4.1.4 INITIALIZE IP MODULE 



4.1.4 INITIALIZE IP MODULE 



This routine it called to initialize the IP module. The 
routine sett up all o£ the data atructurea, opens a SAP with 
the 3A aodule, and opens a SAP with the statistics processor. 

Call foraat 



PROCEDURE initialize_ip_Bodule ( 
VAR status : INTEGErT: 



status OUT This is the status of the 

initialization request returned to 
the caller. This nay be one o£ the 
following values. 
ip_suecess£ul 
ip~insufficient_resources 



Global data accessed 



1. All pointers in the Protocol Status Table will be set to 
NIL. 

2. All counts in the Statistics Data Structure will be set 
to zero. 

3. The timer list will be created. 



General Algorithm 



BEGIN 

Initialize the Protocol status table. 

Initialize the Statistics Data Structure. 

Create the timer list. 

Open a SAP with the statistics processor. 

Open an IPnet SAP with 3A. 
END 
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4.1.5 OPEN SAP PROCESSOR 



4.1.5 OPEN SAP PROCESSOR 



The open SAP routine is called by the ULP module in order 
to open a'^SAP with the IP module. A open SAP allows the ULP 
module to use a specific protocol number and thereby tend 
datagrams out on the network. Each SAP is identified by the 
SAPID that is assigned by the IP module, all communication 
between the modules will use this number for identification. 

Call format 



PROCEDURE ip_open_sap ( 



protocol 
data_ind 
error_ind 
VAR send_req 
VAR sapid 
VAR status 



protocol 



In 



data ind 



IN 



error_ind 

sender eq 
sapid 

status 



IN 



OUT 



OUT 



OUT 



0..255; 
ip_data_ind; 
ip_error_ind; 
ip send req; 

integerT 

ip_status_type); 



This value specifies the user 
protocol to the IP module. The IP 
module will only allow one SAP for 
each protocol number. The ULP must 
specify an appropriate number 
between zero and 255. 

This is a pointer to a user 
supplied routine, which the IP 
module will call to present data 
messages to the ULP. 

This is a pointer to a user 
supplied routine, which the IP 
module will call to present error 
messages to the ULP. 

This is a pointer to the IP 
modules routine to send data. 

This it a 32 bit value that 
identifies the particular IP SAP in 
all later requests. 

This is the status of the 
request. The following values may 



V. y 



'L 
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be returned: 

£p_success£ul 
ip_protocol_inu«e 
ip_protocol_il legal 
ip_in«u£ficient_re«ource8 



Global data aeceised 

1, The Protocol Status Table (PST) is updated and a PST 
record is created. 

2. The Statistics Data Structure (SDS) is updated. 



o 



General Algorithm 



BEGIN 

IF first open_sap call THEN 

Call the initialization routine. 
IFEND 

IF legal protocol number THEN 
IF PST array too small THEN 

Enlarge the PST array. 
IFEND; 

IF protocol number not in use THEN 
Create a PST record. 
Update the PST record pointer. 
RETURN (ip successful) ; 
ELSE 

RETURN (ip_protocol_inuse) 
IFEND 
ELSE 

RETURN (ip_protocol_illegal) 
IFEND 
END 
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4.1.6 PROCESS IP DATAGRAM 



This routine will receive an IP datagram that has come from 
the ULP or 3A module. It will determine where the datagram is 
going, process reassembly, and do fragmentation. 

Call format 



PROCEDURE process_ip_datagram ( 
header : ip_header_rec; 



source 

destination 

options 

data 

VAR status 



: ip_address; 

: ip_address; 

: ip_option_rec; 

: buf_ptr; 

: ip_status_type) ; 



header 



source 



In 



In 



destination In 



options 



data 



status 



This is a record which contains 
the IP header for the datagram. 

This is the address of the 
sender. This address may be 
partially of completely unspecified 
if the datagram can from the ULP. 

This is the address of the remote 
IP that the data is being sent to. 

This is an array trtiich contains 
the option parameter data. 

This is a pointer to a system 
buffer containing the data portion 
of the datagram. 

Out This is the status of the 
request. The following values may 
be returned: 

ip_successful 

ip_net_unreachable 

ip_hos t_unr eachabl e 

ip_fragmentation_needed 

ip_option_error 

ip_sap_not_open 

ip_source_il legal 



In 



In 
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4.0 DESIGN OVERVIEW 
4.1.6 PROCESS IP DATAGRAM 



ip_des t inat i on_i 1 1 egal 
ip__protocol_il legal 






Global data acce««ed 



1. None. 



General Algorithm 



BEGIN 

Process the options; 
- IF no option errors THEN 

CALL the routing aodule; 
CASE route OF 
-ULP- 

IF fragment THEN 

CALL process_ip_fragment; 
ELSE 

IF ICMP datagram THEN 

CALL process_icmp_datagraffl; 
ELSE 

Present the data to the ULP; 
IFEND; 
IFEND; 
-3A- 

Build datagram and send it out through 3a; 
■No route" 

RETURN (error_code_f rom_routing) ; 

Casend; 

ELSE 

RETURN (ip_option_error) ; 
IFEND; 
END 



o 
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4.1.7 PROCESS ICMP DATAGRAM 



This routine will receive ICMP datagrams £ron the 
process_ip_datagraa routine. The routine will generate an 
error indication to the ULP or generate an ICMP datagram and 
send it through 3A. 

Call format 



PROCEDURE proeess_icmp_datagram ( 
source : ip_address; 
destination ; ip_address; 
data : buf_ptr) ; 



source 



destination In 



data 



In This is the address that the 
datagram originated from. 

This is the address that the 
datagram was sent to. 

In This is a pointer to a system 
buffer which contains the data that 
was received in the datagram. 



Global data accessed 



1 . None . 



y 
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General Algorithm 



BEGIN 

Pull the ICMP header out of the data buffer. 
CASE error_type OF 
-icmp_echo_repl5r" 

Do nothing. 
- i c«p_t i»e_r ep 1 jr- 

Do nothing. 
" i cap^inf o_r ep 1 y- 

Do nothing. 
« i cap_des t_,unr eachab 1 e~ 
CASE error_code OF 

0: ULP~error_ind (ip_net_unreachable) ; 
1: ULP~error~ind (ip_hoit_unreachable) ; 
2; ULP~error~ind (ip__protocol_unreachable) ; 
3: ULP~error~ind (ip_port_unreachable) ; 
4: ULP~error~ind (ip_fragnentation_needed) ; 
5: ULP~error~ind (ip_route_failed) ; 
CASEND; 
■ i eap_s ource_quench" 

ULP_error_ind (ip_congestion) ; 
■ic«p_redirect~ 

Infora IP routing aodule; 
•"icap echo requeit" 

Strip the firit 4 bytes froa the data buffer; 
Generate_icap_datagraa (dest, arc, 0,0, 0,0, data) ; 
"icBp_tiBe_exceeded- 
CASE error_eode OF 

0: ULP~error_ind (ip_tiBeout) ; 

1: ULP^error^iad (ip~ai«eably_tiaeout) ; 

casend; 

-i cap jparaaet er_err or- 

ULP_error_ind (ip_option_error) ; 
-icap tiae_requeit- 

Strip the first 4 bytes froa the data buffer; 

Update the tiaestaaps in the data buffer; 

Generate_icap__datagraa (dest, arc, 14, 0,0,0, data) ; 
"icap info_request" 

Strip the first 4 bytes froa the data buffer; 

Generate_icap_datagraa (dest, src, 16, 0,0,0, data) ; 
CASEND; 
END 
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4.1.8 PROCESS IP FRAGMENT 



Thii routine is called by the proce««_ip_datagr«B routine 

to process a datagram fragment. I£ the fragment contains the 
correct header information then the fragment in added to the 

datagram buffer chain. If the datagram is completely 

assembled then the datagram will be presented to the user and 
the structure will be released. 

Call format 



PROCEDURE process_ip_£ragment ( 
header : ip_header; 



source 
destination 
options 
data 



header 



source 



In 



In 



destination In 



options 



data 



In 



IN 



: ip_address; 

: ip_address; 

: ip_option_rec; 

: buf_ptr); 



This is a record containing the 
header information that came in the 
datagram. 

This is the source address from 
the IP header. 

This is the destination address 
from the IP header. 

This is an array of bytes which 
contains the options from the IP 
header. 

This is a pointer to a system 
buffer trtiich contains the data that 
came in the datagram. 



Global data accessed 



1. This routine will access the protocol_status_table to 
find the address of the reassembly buffer. 
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2. The routine will then access the reassembly buffer, add 
the datagram to the buffer if appropriate, and release 
the buffer i^en the datagram is completed and presented 
to the ULP. 

3. The timer entry for the reassembly buffer will be 
updated. 



General Algorithm 



BEGIN 

IF a reassembly buffer exists for this protocol THEN 
IF header fields and options match THEN 

Find the correct place in the linked list. 
Insert the new data into the linked list. 
IF datagram completed THEN 
Deliver datagram to ULP. 
Release the buffer space. 
Release the timer entry. 
ELSE 

Update the timer entry. 
IFEND; 
ELSE 

Do nothing. 
IFEND; 
ELSE 

Create a reassembly buffer and store the data. 
Create a timer entry for the buffer. 
IFEND; 
END 



\,^ 
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4.1.9 PROCESS TIMER EVENT 



This routine is called by the executive to process the 
expiration o£ a system timer. The routine processes the timer 
list and releases any reassembly buffers whose timers have 
expired. The executive timer will expire periodically once a 
second. 

Call format 



PROCEDURE process_timer_event ( 
parameter : tCELL) ; 



parameter 



In This is the parameter that was 

passed to the executive when the 
timer was initiated. 



Global data accessed 

1. The the timer list will be accessed and expired timer 
records will be released. 

2. The reassembly buffer of any timer record that is 
released will also be released. 



General Algorithm 



BEGIN 

cur^rec :- timer_listt.next_rec; 
cur""rec*. delta ;- cur_rect. delta - 1; 
WHILE cur_rect.delta-0 DO 

Delete~the buffer pointer to by cur_rect.buffer_ptr; 

timer_listt.next_ptr :- cur_rect.next_rec; 

Release the timer rec pointer to by cur_rec; 

cur rec :" timer_list*.next_rec; 
WHILEND; 



V, 
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END 
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4.1.10 RECEIVE ULP DATA 



The receive_ulp_data routine is called by the ULP in order 
to send data" out to some other host on an IP network. The 
address of this routine is given to the ULP when an open 
request is made. 

Call format 



PROCEDURE receive_ulp_data ( 
header : ip_header_rec; 
source : ip_address; 
destination ; ip_addr ess; 
options : ip_option_rec; 
sapid : INTEGER; 
data : buf_ptr; 
VAR status : ip_status_type); 



header 



source 

destination In 

options 

sapid 

data 

status 



In This is a record which contains 
the IP header for the datagram. The 
ULP module does not fill in the 
entire header only the user 
specified fields as noted in the ERS 
t4]. 

In This is the address of the 
sender. This address may be 
partially of completely unspecified 
if the datagram can from the ULP. 

This is the address of the remote 
IP that the data is being sent to. 

In This is an array which contains 
the option parameter data. 

In This is the SAPid returned by the 
original open request. 

In This is a pointer to a system 
buffer containing the data portion 
of the datagram. 






Out 



This is the status of the 
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request. The following values aay 
be returned: 

ip_suecess£ul 

i p_^ne t_unr eachab 1 e 

ip_hos t_unr eachab 1 e 

ip_fragnentation_needed 

ip_option_error 

ip_«ap_not_open 

ip_souree_il legal 

ip_destination_il legal 

ip_protocol_il legal 



Global data accessed 

1. The PST is accessed to validate the SAPID and to 
- detemine the protocol number. 

2. The packet and byte counts in the SDS are updated. 



General Algoritha 



BEGIN 

IF valid SAPID and protocol THEN 

CALL pr©eess_ip_datagra« (status); 
RETURN (status)! 
IFEND; 
END 



o 
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This routine ii called by the 3A aodule to present data 
indications. As each datagram is received from the network it 
will be delivered to the ULP, be added to the appropriate 
reassembly buffer, or be sent back to 3A. If the datagram is 
damaged or undeliverable then it will be discarded and an ICMP 
datagram will be sent back to the source. 

Call format 



PROCEDURE receive_3a_data ( 
multicast : BOOLEAN; 
receive_netid : net_id_type; 
sending_sysid : sys_id_type; 
VAR datagram : buf_ptr) ; 



multicast In 



receive net id In 



sending_sy8id In 



This flag will 
datagram was sent 
datagram. 



be TRUE if the 
as a broadcast 



datagram 



In 



This is the network identifier of 
the network solution that the 
datagram was received on. 

This the system identifier of the 
system that transmitted the 
datagram. 

This is a pointer to the system 
buffer which contains the datagram. 



Global data accessed 

1. May access the protocol status table. 

2. Hill update the SDS counters. 



^r^. 
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General Algorithm 



BEGIN 

Pull the IP header out of the buffer; 
Unpack the source and destination addresses; 
CALL process_ip_datagr«D (status) ; 
IF status<>ip_successful THEN 
CALL generate_icap_datagram; 

ifend; 

END 



o 



o 
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4.1.12 RECEIVE 3A STATUS 



This routine it called by the 3A module to present status 
indications. Since the IP nodule relies upon the IP routing 
module £or routing decisions it does not need to know the 
status o£ networks, however, the statistics reporting requires 
that IP know what network solutions should be reported about. 
Therefore, this routine will check the active SOS buffer, if 
it receives an indication about a network that is not in the 
buffer it will add it. 

Call format 



PROCEDURE receive_3a_status C 
nib__ptr : nib__type) ; 



nib_ptr In This is a pointer to the 

information block of the network 
whose status has changed. 



Global data accessed 



1. This routine will add networks to the active. SDS buffer. 



4"^ 
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General Algorithm 



BEGIN 

Search the active SDS bu££er for the network id. 
IF (status is UP) AND (not found) THEN 

Add the network to the buffer. 
ELSE 

IF (status is DOWN) AND (found) THEN 
Force statistics for this network. 
Renove the record for this network. 
ELSE 

Do nothing. 
IFEND 

ifend; 

END 



G 



O 
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A . 1 . 13 STATISTICS_PROCESSOR 
Call £orfflat 



PROCEDURE •tatitties_proeefsor ( 



sds_hdr 
function ; 


. tsds_header; 

; statistics_£unction_eodes; 


reason 
time 
par am 
VAR status 


; statistics_reason_type; 

! report time type; 

! ♦cell;" 

: statistics function status) ; 
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sds hdr In This is a pointer to the header 
~ record of the statistics data 

structure. 

function In This is the type of operation to 

be performed. 

reason In This code indicates the reason 

that the statistics are being 
reported. 

time In This is starting and ending time 

of the period that statistics should 
be reported for. 

param In This is a pointer for use when 

the report is forced. 

status Out This is the status returned to the 

caller. 



Gl obal data accessed 



1. This routine will read and write the SDS tables. 



j^' 
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General Algorithm 



BEGIN 

CASE function OF 

■•ii»ue_report_and_clear^buf£er«" 

Build a log aetsage from the inactive bu££er. 
Send the log aessage. 
Clear the inactive buffer. 
-clear__buffer«- 

Clear the inactive buffer, 
■s tart_col lect ing" 

Do nothing. 
■« t op_c o 1 1 ec t ing" 

Do nothing. 
"lelect bufferl- 

IF local pointer set to buffer 2 THEN 

Copy the network table to SDS buffer 1. 
Set the local pointer to buffer 1. 
IFEND 
-•elect bufferl- 

IF local pointer aet to buffer 1 THEN 

Copy the network table to SDS buffer 2. 
Set the local pointer to buffer 2. 
IFEND 
CASEND; 
END 
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4.2 DATA STRUCTURES 



The ICMP datagrams use the following set of codes 
error code field that they contain. 

CONST 

icinp_echo_reply "0, 
icBp_dest_unreaehable ■ 3, 
icmp_source_quench ■ 4, 
ici»p_redirect "5, 
icmp_echo_request ■ 8, 
icmp_time_exeeeded ~ 11, 
icmp_parameter_error " 12, 
icinp_tiine_request ■ 13, 
icinp_tiiiie_reply ■ 14, 
icinp_info_request ■ 15, 
.icnp_info_reply "16; 



for the 



TYPE 

icap_statu8_type 



ic«p_echo_reply. . iciiip_inf o_reply; 



s / 



i 
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4.2.1 PROTOCOL STATUS TABLE 



The protocol ttatue t»ble (PST) is used to keep track of 
the current condition of each protocol number. The PST it an 
array of pointer! , irtxere each active protocol nunber has a 
pointer to a record trtiich contains the current status of the 
user of that protocol number. If a particular protocol number 
is not in use then the pointer will be NIL and no PST record 
will exist. The size of the PST will increase and decrease 
dynamically as SAPs are opened and closed. An active PST 
record may point to a chain of reassemble buffers. 



CYBIL data definitions 



TYPE 

pst_array - ARRAY [*] OF tpst_rec; 

pst_rec - RECORD 



sapid 




INTEGER, 




protocol 




0..255, 




prev__ptr 




♦pst_rec. 




next ptr 




♦pst_rec. 




data ind 




ip_data_ind. 


. 


error ind 


: 


ip data_ind, 




rbuf_ptr 


• 
• 


treassembly_ 


buffer 


sds ptr 


• 
e 


♦ ip_protocol. 


_rec. 


RECEND; 








VAR 








pst_size ; integer; 





o 



Creation/Modification 



1. The base array of the PST is dynamically allocated by 
the open and close SAP routines. On the first call to 
the open SAP routine the array will be created. 

2. As each SAP is opened by the ULP, the open_sap routine 
will create a PST record containing all of the received 
information. The pointer in the base array will then be 
updated to point to the new record. IF necessary the 
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PST array will be enlarged. 

3. When a SAP is closed by the ULP, the close_sap routine 
will set the pointer in the base array to NIL and 
release the PST record. All buffers in use for 
reassembly will also be released. If there are nore 
than ten pointers at the end of the PST array that are 
not active, then the size of the array will be 
decreased. 

4. Many of the IP routines will use the information in the 
table but the only routines that modify the table will 
be the open and close SAP routines. 



K.^y 



1^ 
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4.2.2 REASSEMBLY BUFFER' 



Each protocol will have a chain of reaatenbly buffers. 
Each buffer it constructed as a linked list with a header 
record and a list of snaller records that identify each piece 
of data in the buffer. The data which makes up each segment 
of the datagram being reassembled will remain in the system 
buffer that it was received in, however, it will be appended 
to buffers containing adjoining data. When the buffer is 
completed it will be contained in a single buffer. Each 
reassembly buffer will have an entry in the timer list which 
is used to limit the time used in the reassembly process. 



CYBIL data definitions 






TYPE 

reassembly^buffer 
next_buffer 
first_rec 
timer_ptr 
source 
destination 
identifier 
precedence 
security 
first_frag 
last frag 
RECEND," 



RECORD 
freassembly_buffer, 
♦buffer_rec, 
♦timer_rec, 
ip_address, 
ip address, 
0.70FFFF(16), 
0..7. 

ip_security, 
BOOLEAN, 
BOOLEAN, 



BUFFER REC - RECORD 



first_group 
last_group 
next rec 
data" 
RECEND; 



Creation/Modification 



INTEGER, 

INTEGER, 

treassembly_buffer, 

>uf_ptr. 



o 

x^' 



1. Each reassembly buffer will be created, maintained, and 
released by the routine that reassembles datagrams. 
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2. A lingle reassembly buffer may be released by the timer 
routine if the reassembly time expires. 



,'f"^:. 
\.j 
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4.2.3 STATISTICS DATA StRUCTURE 



o 



o 



The statistics compiled by the IP aodule are stored in the 
structure described in this section. The data is updated by a 
ntimber of routines throughout the IP aodule and the overall 
reporting and control is done by the statistics processor. 



CYBIL data definitions 



TYPE 

ip__sd8__buffer - RECORD 

open_count : £our_byte_statistic_record, 

close_count : four_byte_statistic_record, 

protocol_list : ♦ip__protocol_rec, 

network_list : ♦ip_network_rec, 
RECEND, 

ip_protocol_rec - RECORD 

bytes_sent : £our_byte_statistic_record, 

datagrams_sent : four_byte_statistic_record, 

bytes_recaived i four__byte_statistic_record, 

datagraiBs_received : four_byte_statistic_record, 

resource_errors : four_byte_statistic_record, 

content_errors : four_byte_statistic_record, 

next_rec ; ♦ip_protocol_rec, 

RECEND, 

ip_network_rec - RECORD 

~network__id : network_id_type, 

network_naae : tCELL, 

local : ARRAY [0..5] OF four_byte_statistic_reco 

forward : ARRAY [0..5] OF four_byte_statistic_reco 

next rec : tip_network_rec, 
RECEND;" 



Creation/Modification 

1. The main structure of the SDS will be allocated upon 
initialization of the IP aodule. 

2. The individual network records will be created by the 3A 
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status processor.' 

3. When the buffer is changed all active networks will be 
copied from the old buffer to the new buffer. 
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4.2.4 TIMER LIST 



o 



The tiaer list it a linked lilt of records. The first 
record marks the head of the list and is not used for data. 
The list is ordered by the time duration for each entry. Each 
entry in the list contains a time value which represents the 
interval of time which must expire after the preceeding record 
is removed from the list. This format requires more time when 
adding and deleting entries, but is very simple to process 
tdien checking for expired timers. 



CYBIL data definitions 



TYPE 
- ip_timer rec - RECORD 

time_delta : INTEGER, 
aext_rec : ♦ip_timer_rec, 
buffer_ptr : ♦rea8sembly_buffer, 
RECEND; 

VAR 

timer list : ^timer rec; 



Creation/Modification 

1. The first (base) record of the list is created by the 
initialization routine and always exists. 

2. When each reassembly buffer is created, a timer record 
will be created. 

3. As each datagram is processed the timer record may be 
updated. 

4. When a reassembly buffer is deleted the corresponding 
timer record will also be deleted. 



o 
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4.3 INITIALIZATION 



The IP module will initialize itself when the first SAP ii 

opened. A static variable will be used by the open_sap 
routine to determine if it is being called for the first time, 
and if so then the data structures will be initialized, a SAP 
will be opened with the statistics processor, and a SAP will 
be opened with the 3A intranet layer. 
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4.4 DESIGN CRITERIA AND ALTERNATIVES 



The IF aodule will process each datagran that comes from 
and goes to an IP network. It is therefore important that the 
IP aodule process each datagram as quickly as possible and use 
the smallest amount of resources possible. 



The IP aodule does not run as a separate task because of 
the (hopefully) small amount of time it will use to process 
each request, and the need to avoid the overhead of intertask 
messages often used for intertask communication. 



One possible sacrifice of efficiency is the separation of 

the routing tasks into a separate module. This is a good 

logical grouping of functions, but could add additional 
procedure calls not otherwise needed. 
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